home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / hardware-part1 / 9356 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.2 KB  |  69 lines

  1. Path: news.mountain.net!usenet
  2. From: gene_heskett@wvlink.mpl.com (Gene Heskett)
  3. Newsgroups: comp.sys.amiga.hardware
  4. Subject: Re: IV-24 Chroma Keying
  5. Date: 06 Apr 96 00:06:55 +0500
  6. Organization: MountainNet, Inc. Morgantown WV 800.444.1458
  7. Message-ID: <2863.6670T6T2778@wvlink.mpl.com>
  8. References: <225.6668T456T546@student.uq.edu.au>
  9. NNTP-Posting-Host: slip6.mpl.com
  10. X-Newsreader: THOR 2.22 (Amiga;TCP/IP)
  11.  
  12.  
  13.  PH>         Phil Hoffmann
  14.  
  15. "Do I need extra hardware?" - Yes, Phil.  While its theoretically
  16. possible to do a "chroma key" in software alone given a cpu that runs
  17. at many hundreds of megahertz, the software hasn't yet been written
  18. to allow that.
  19.  
  20. What a "chroma key" is, is a signal that tells the video effects unit
  21. to substitute one video source for another *when* the color picked as
  22. the key color appears coming out of the source, normally a camera
  23. whose outputs are in the form of individual red, green, and blue
  24. signals.  Its possible to do it with a composite ntsc signal also,
  25. but this means that either the key source run well over a microsecond
  26. ahead of the main videos in order to have time to decode the ntsc
  27. signal back into RGB.
  28.  
  29. Normally, the RGB signals are fed into a rather unique video bridge.
  30. This "bridge" detects the relative levels of the 3 colors and outputs
  31. a signal thats true only when the correct color is detected.  The
  32. signal is used to drive the video switcher to effect the source
  33. switch from one picture to the other.
  34.  
  35. The requirement for the hardware becomes obvious when you consider
  36. that this *must* be done, on *both* edges of the color, in well under
  37. 30 nanoseconds, or *both* of the video signals must be delayed by the
  38. amount of the delay in the color detector circuitry.
  39.  
  40. As video speed, clean, no ringing allowed, tap-able (so you can get
  41. an exact time match) delay lines tend to be sold by the microsecond,
  42. both technics are used.  Why?  If this delay matching isn't done,
  43. then the keyed image and the key won't be in time, allowing the key
  44. color to show on one edge, and trimming the inserted image before its
  45. edge on the other.  I'm sure you've seen the effect once or twice on
  46. locally produced newscasts etc.
  47.  
  48. This key signal generator can run rather nicely from the RGB outputs
  49. normally fed to the monitor on a amiga running an ntsc hi-res-laced
  50. screen, and which is genlocked to the station sync.  We did do it
  51. that way here for a bit.  In our case now, the keyer itself is in the
  52. miggy, in the form of a color zero output from a Magni type
  53. genlocker, or the key signal from the toaster.  We use both depending
  54. on the application at hand.  We could, and did for a while, send the
  55. RGB right into our Grass 300's internal chroma keyers, but as we
  56. couldn't get enough range to time all sources, and the miggy was off
  57. the most, it went.  The miggy generated key is actually better timed
  58. in this case.
  59.  
  60. Of course you can't see it in the toaster drawings since they don't
  61. furnish any, but that miggy keyer is hardware nonetheless.
  62.  
  63. /*            Gene Heskett          |  I need help, please see my adv. */
  64. /*  CE @ WDTV Weston/Clarksburg WV  |  in the newsgroup 'alt.tv.jobs'  */
  65. /*  <gene_heskett@wvlink.mpl.com>   |  We are an equal opportunity and */
  66. #include <std.disclaimer>           |  all that stuff employer.
  67.  
  68.  
  69.